Import the wires from spec. Here we go!

When we get a node announcement out, we can now pull out its offer
characteristic

Correctly mark whether or not the TLV's are the same/different, given two
node announcements

If there's a rate-card for liquidity, we don't know about it until
after startup (the plugin *should* call us at init to tell us what their
current rates are)

Changelog-Experimental: JSON-RPC: new RPC `setleaserates`, for passing in the rates to advertise for a channel lease (option_will_fund)

Note that we use the names from the spec.

Changelog-Experimental: JSON-RPC: `listnodes` now includes the `lease_rates`, if available

A couple of the fields for liquidity_ads are u16

If received lease rates are empty (all zeroes), turn them off

As we move to advertising liquidity, set the default to not have any
fuzz. This means we won't randomly reject an offer to buy liquidity.

Implement support for liquidity ads in `funder` plugin. We set the
command line options for the leases, as well as sending the updated ads
to lightningd (who then passes them through to gossipd)

Make sure everything updates/flows through as expected.

convenience, mostly

When we accept a bid to create a channel lease, we send back a signature
committing to our max channel lease amounts.

When a request comes through, we forward it over to the funder who
uses the currently set policy to figure out how to handle it.

Includes small update to the policy engine which decides whether or not
to fund a request.

Changelog-Experimental: Plugins: `openchannel2` hook now includes optional fields for a channel lease request

Changelog-Experimental: EXPERIMENTAL-DUAL-FUND: JSON-RPC: openchannel_init now takes a `requested_amt`, which is an amount to request from peer

Changelog-Added: JSON-RPC: `fundchannel` now takes optional `request_amt` parameter

Adds new tables to database, backfills, basically copies the fee_rates
state machine for channeld.

Useful for parsing a passed in feerate before calling lightningd with
it, e.g. when you need to know what the feerate is for a fundpsbt before
calling fundpsbt

Changelog-Added: JSON-RPC: new command `parsefeerate` which takes a feerate string and returns the calculated perkw/perkb

If the channel is under lease, the lessor's (accepter, really)
funds have a CSV lock that reflects the length of the remainder of the
lease.

Channel leases modify the CSV height that an output is eligible for
being spent at,  persist this to the database

If an output's CSV lock hasn't been surpassed yet, don't try to
include it in a transaction

Typically we forget a channel if 2016 blocks have passed and
the funding transaction hasn't been mined yet, however we
SHOULD NOT forget these channels if we've got funds in them!

If the channel is leased and our peer is too far behind, fail the
channel.

By default, we won't close a channel that we leased to a peer.
You can override this with the `force_lease_closed` flag.

Changelog-Added: JSON-RPC: close now has parameter to force close a leased channel (option_will_fund)

We need to update the peer wrt our blockheight on reconnect

We're gonna need them

We need to know what the lease we're expecting is. To do this
we pass around the hex encoded portion of the wire format.

We can use this passed in expected lease rates to confirm that the peer
is, in fact, using the same rates as what we have currently.

Changelog-Added: JSON-RPC: fundchannel, multifundchannel, and openchannel_init now accept a 'compact_lease' for any requested funds

We need to parse the feerate string, so we can figure out what our
weight fee will be for a leased channel, so we go get the feerate
and use that to calculate what our expected lease fee will be for
the requested amount.

If there's no plugin currently in place, we simply won't return any
funding at all, in which case we'd expect them to handle however
they want. (our implementation would fail the open, as we only accept
opens that have at least as much as we've requested provided)

Make it easier to figure out what the inputs were to check_balances
on two failure cases

We need the 'actual' accepter's funding for the reserve calculations,
which includes the lease fee that the opener is paying them, so we
calculate it before doing all that jazz.

However, we MUST send the actual "on paper" (e.g. without lease fee)
amount to the peer in accept_channel2, so we stash the original amount
and send it.

with channel leases, we use the open_tlv data after a round of talking
to the peer (which clears out the tmpctx). It'll get cleaned up
when this peer opens/fails.

Check that channel leases work as expected for unilateral closes
and cheats!

Since we now use 'compact_lease' to gate an open (if the rates have
changed, we fail), we no longer need to rely on query rates for figuring
things out, so we make it dev-only.

Changelog-Changed: JSON-API: queryrates is now developer only

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

We don't actually use the NULL-is-equal in the one caller, so ignore that.

Signed-off-by: Rusty Russell <[email protected]>

And fix up lease_rates_fromhex to be the obvious calling convention.

Signed-off-by: Rusty Russell <[email protected]>